**Fault tolerance 容錯是在 High Availbility 很重要的一環與假設, 因為我們知道在高有效性的目的就是避免失效/失能, 但我們知道沒有一個不存在任何錯誤的系統, 所以就設計一套系統把可能的錯誤給放進去, 這樣系統就比較 Rigid 完固.

在基本的容錯系統有下面四點的假設:

1. No single point of failure

2. Fault isolation to the failing component

3. Fault containment to prevent propagation of the failure

4. Availability of reversion modes**
   要去做到上面這四點必要做到:

5. 複製 Replication: 一個為了要確保重複的系統, 最簡單的就是一直複製.

6. 重複 Redundancy: 一個重覆的資源與資訊, 看起來是很浪費資源的, 但有時確是很有必要的.

7. 多元 Diversity: 會出錯的原因可能都是相同, 若重複會出錯的流程可能還是錯的.

在設計上我們要去注意到的是

1. 流程: 每一個訊號的環節都有可能出錯, 要確保流程的穩定, 最好是一開始就有不同的流程能夠去接受其資訊, 包含輸出入, 以及計算的環節.

2. 資料庫: 儲存往往是成本最高的系統, 因為資料量一直會累積, 且無時效性, 尤其是最後看得是結果的話, 要如何確保資料最後儲存的正確性是最重要.

在之前要確立三件事情:

* How critical is the component? 這個元件的重要性多高, 是可有可無? 還是若沒有一定會掛?
* How likely is the component to fail? 這元件有多少機率會有問題? 是高還是低?
* How expensive is it to make the component fault-tolerant? 這元件的成本若要做到容錯的成本多高?

事實上並不是所有的容錯率不是說都不能錯誤, 有時要去思考的是如何知道是錯的, 這就是如一開始所說的 Monitor, 以及後面要講的 Watchdog 的方式來知道錯誤, 而能夠及時的重做就夠了, 因此往往一開始要確保的是:

1. 是否能夠收集足夠的資料能夠重做?
2. 在重做的過程中是否能夠減少所須要的資源?

最近很多 Load Balancing System 都變成 Job Queuing System, 因為在某方面確保工作能夠被正確執行外, 在無法被正確執行如何繼續接下來做是也是相當重要, 且若須要保證這些工作都能夠被執行到, 須要的不只是負載均衡, 而是一個工作排隊/排程系統了.

有時我覺得要做出一個可以運作的系統不難, 但若要做到怎樣都不會壞的系統的功夫比只是做出來難上許多倍, 甚至是工夫與成本也是多上更多倍, 因此有時我都很相信, 一個系統的好壞先從效率以及有效性開始看起, 若沒有人用, 或一直常出問題的系統就跟本不是個好系統.